Hello there! We had a user @rolandoam report trouble running ruby_llm on JRuby due to some Zeitwerk incompatibilities. Those issues are now resolved on JRuby master (10.0.x) and I wanted to start getting JRuby into your CI to prevent any future breakage.

The changes here get the test suite running and it mostly passes. There's two kinds of failures that remain:

• All of the "handles context length exceeded errors" tests fail because they try to load a very large YAML file. JRuby's implementation of Psych (Ruby YAML stdlib) uses the SnakeYAML-Engine library, which has a default limit in input size to prevent DOS attacks. As a result we raise a different error for the excessive content:

  6) RubyLLM::Chat real error scenarios openrouter/anthropic/claude-3.5-haiku handles context length exceeded errors
     Failure/Error:
       expect { chat.ask('Hi') }.to raise_error(RubyLLM::Error) do |e|
         # Basic error format checks
         expect(e.message).not_to look_like_json
         expect(e.message).to match(/^[A-Za-z]/)
       end
     
       expected RubyLLM::Error, got #<Java::OrgSnakeyamlEngineV2Exceptions::YamlEngineException: The incoming YAML document exceeds the limit: 3145728 code points.> with backtrace:
         # org.snakeyaml.engine.v2.scanner.ScannerImpl.fetchMoreTokens(ScannerImpl.java:304)
         # org.snakeyaml.engine.v2.scanner.ScannerImpl.checkToken(ScannerImpl.java:193)
         # org.snakeyaml.engine.v2.parser.ParserImpl$ParseBlockMappingKey.produce(ParserImpl.java:712)
         # org.snakeyaml.engine.v2.parser.ParserImpl.lambda$produce$1(ParserImpl.java:232)
         # java.base/java.util.Optional.ifPresent(Optional.java:178)
         # org.snakeyaml.engine.v2.parser.ParserImpl.produce(ParserImpl.java:232)
         # org.snakeyaml.engine.v2.parser.ParserImpl.hasNext(ParserImpl.java:226)
         # org.jruby.ext.psych.PsychParser.parse(PsychParser.java:248)

We currently allow these exceptions to be raised directly from the YAML engine, which could be causing this to fail in a different way than you expect. This behavior accounts for six out of the eight failures.

• The two remaining failures appear to be similar, both handling extended character sets in Tool#name. For some reason we're getting a nil result during the processing of the tool's name.

  7) RubyLLM::Tool#name normalizes class name Unicode characters to ASCII
     Failure/Error:
       normalized.encode('ASCII', replace: '')
                 .gsub(/[^a-zA-Z0-9_-]/, '-')
                 .gsub(/([A-Z]+)([A-Z][a-z])/, '\1_\2')
                 .gsub(/([a-z\d])([A-Z])/, '\1_\2')
                 .downcase
                 .delete_suffix('_tool')
     
     NoMethodError:
       undefined method '[]' for nil
     # ./lib/ruby_llm/tool.rb:59:in 'name'
     # ./spec/ruby_llm/tool_spec.rb:16:in 'block in <main>'
     # ./spec/spec_helper.rb:105:in 'block in <main>'
     # ./spec/spec_helper.rb:104:in 'block in <main>'

The '[]' method reported here is actually due to normalized.encode('ASCII', replace: '') incorrectly trying to call [] on the string '' used for the ':replace` option rather than using it as-is. I think we're doing something wrong here.

I have fixed the encoding issue in jruby/jruby#8873 and bumped up the Psych codepoint limit in this PR and now ruby_llm is green on JRuby!

I'd love to see it green in your CI too... could someone approve the workflow?

The encoding fix will be in JRuby 10.0.1.0 so for now I've bumped the CI job to use jruby-head.

Would be awesome to make RubyLLM run on JRuby as well!

However, the overcommit hooks are there for a reason. Can you fix the rubocop errors by running rubocop -A?

Thank you for approving the run!

I will fix the issues, but I strongly disagree with the strict alphabetical ordering of dependencies. In this case, jdbc-sqlite3 is the alternative library for sqlite3 and it makes much more sense to have related platform-specific dependencies near each other. The move of activerecord-jdbcslite3-adapter is less of a concern.

In general I believe that related dependencies should be grouped together in a Gemfile rather than alphabetically ordered, which results in related deps being placed far from one another. When you need to inspect dependencies, logical groupings make it much easier to manage.

But it's your project and I'll comply!

I agree with you. If with a rubocop disable comment you're able to skip the alphabetical ordering only for the JRuby dependencies I'd prefer that.

@crmne Oops, I already pushed the change. I can reverse it with a comment if you would prefer.

@headius if there's a comment that would keep the alphabetical order enabled for all deps except JRuby that's what I would prefer. Otherwise the current commit works for me.

@crmne There doesn't seem to be a way to exclude just the JRuby dependencies, unfortunately.

Ok. I'll keep the JRuby dependencies in mind when looking at that list. Thank you!

Looks like there's one last thing to fix (with a comment)

I figured out that commenting the dependencies and sorting them within that smaller group solves both cops. rubocop -A is green now.

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 88.91%. Comparing base (1212984) to head (6a08ac0).
Report is 1 commits behind head on main.

@@            Coverage Diff             @@
##             main     #255      +/-   ##
==========================================
- Coverage   89.72%   88.91%   -0.81%     
==========================================
  Files          75       75              
  Lines        2812     2860      +48     
  Branches      556      556              
==========================================
+ Hits         2523     2543      +20     
- Misses        289      317      +28     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.